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abstract Program transformations often involve the generalization of a function to take additional arguments 
It is shown that in many cases such an additional variable arises as a representation of the continuation or global 
context in which the function is evaluated. By considering continuations, local transformation strategies can take 
advantage of global knowledge The general results are followed by two examples- the a-p tree pruning algorithm 
and an algorithm for the conversion of a propositional formula to conjunctive normal form 
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1. Introduction 

The notion of program transformation is a programming paradigm which combines the 
notion of stepwise refinement {4, 10, 29] with traditional optimization techniques. Under 
this paradigm, one writes a clear, correct, though possibly inefficient, program, and then 
transforms it via correctness-preserving transformations into a program which is more 
efficient although probably less clear. Some of the classes of program transformations are 
local simplification, partial evaluation (or unfolding), abstraction (or folding), and gener¬ 
alization [28]. The generalization transformation replaces a function by some generalization 
which may be more amenable to subsequent manipulations. Typical generalizations 
include the introduction of additional variables or the extension of a function to deal with 
a list of inputs. Typical strategies for generalization involve pattern matching between 
compatible but nonidentical goals [1,2, 28]. 

In this paper we present a different strategy for generalizations: the use of continuations. 
A continuation is a data structure which represents the future course of a computation. 
The use of continuations makes the global context of a computation available in the local 
context, and therefore allows the standard local transformations to use this global infor¬ 
mation. Our strategy is to obtain tractable closed forms for continuations. By studying the 
interactions between a function and its continuation, useful transformations can be made. 

Many of these transformations are probably familiar to assembly-language program¬ 
mers, since the machine-level programmer usually has access to a continuation variable, 
the run-time stack. Despite this fact, we believe that our account of these techniques is 
useful, since it liberates them from the realm of undocumented “coding tricks” and 
transports them to the source-language level where they can be used by a wider class of 
programmers. Furthermore, we will see that such heuristics as “add an accumulator” or 
“generalize to a list of arguments” may be derived from transformations on continuations, 
rather than being merely instances of isolated cleverness. 
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Section 2 of this paper presents our source language (a dialect of Lisp) and our major 
method of proof, subgoal induction [16]. Section 3 illustrates the notion of a continuation 
and presents examples of the kind of manipulations that are performed on them. In Section 
4 these techniques are applied to the problem of a binary (or tree-structured) recursion 
pattern. In Section 5 our techniques are applied to two moderate-sized examples: the a-f 
tree search algorithm and the conversion of propositional formulas to conjunctive normal 
form. Section 6 presents a summary and conclusion. 

2. Preliminaries 

In this section we describe our language, a syntactically sugared dialect of Lisp, and we 
descnbe the verification method we employ, the method of subgoal induction [28]. 

2.1 The Source Language. We define functions by recursion equations, e.g., 

F(x, y) <= if p(x) then y .this is a comment 
else a(b(x),F(c(x),y)) 

This style of definition has a long history [14, 15, 21]. We often use sets of simultaneous 
recursion equations. We usually use uppercase for the names of functions we are defining 
(e.g., F above) and lowercase for functions which are assumed elementary (e.g., a, b, c, and 
p above). Such functions are often left unspecified. We refer to these functions as trivial 
and to the ones we define by equations as serious [19]. Occasionally we use the arithmetic 
functions, which we write in infix notation. End-of-line comments are preceded with 
semicolons. Side effects are not permitted. 

We will have occasion to use list processing, for which we use notation adapted from 
[7J. If x,y, and z are variables, [xy z] denotes a list whose three elements are the values of 

x, y, and z. If the value of y is a list of N elements, then the value of [x !y] is a list of 
N + 1 elements whose first element is x and the remainder of whose elements are those of 

y. We use hd and tl to select the first element of a list and its remainder; thus 

hd([x\y]) = x, tl{[x\y\) =y, 
hd([x y z]) = x, tl([x y z]) = [yz]. 

Similarly, [xylz] denotes a list whose first two elements are equal to x and y, and 
whose remainder is equal to z. [ ] denotes the empty list. The function appendix, y) con¬ 
catenates two lists nondestructive^; append is associative, so we will sometimes write 
appendix, y, z). 

We will also occasionally use temporary functional objects passed as arguments. Such 
objects, called closures, are created using \-notation. For example, the definition 

F(x, y) <= MAPHD(\z [x ' z], y) 

MAPHD(f, x) «= if x = [ ] then [ ] 

else \f(hd(x))' MAPHD(f, //(*))] 

passes a functional object as a parameter to MAPHD. The value of x inside the closure is 
the value at the time the closure was created; that is, we use lexical or static scoping [17, 
26], Thus FI 3, [[I] [2] [3]]) evaluates to [[3 1] [3 2] [3 3]]. MAPHD is a generally useful 
function which we shall take as pnmitive Another useful function is MAPI which is 
defined as 

MAP'tfa , x) e= if x = [ J then a 

else f(hd(x), MAP\f, a, tl(x))) 

where / is a function of two arguments; MAP'lsum, 0, x) returns the sum of the elements 
of x. 

2 2 Subgoal Induction Our major method for proving properties about recursion 
equations is the method of subgoal induction [16], which is an easily understood refinement 
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of earlier methods [13,14]. For each serious function F(x,y), we introduce an input-output 
specification fa(x, y, z) which is a condition on the input parameters x, y and the output 
value z. The principle of subgoal induction states that if the verification conditions (which 
we are about to describe) are true, then the function satisfies its specifications, that is, if F 
halts on input (x, y), then tp F (x, y, F(x, /)) is true. There is one verification condition for 
each branch of the equation. The verification condition for each branch has the form 
A & B & C =* D, where A is the condition for taking that branch, B says that all serious 
function calls on this branch satisfy their specifications, C says that equal arguments to a 
serious function give equal answers, and D says that the final value on this branch satisfies 
the desired specification. New variables are introduced throughout to eliminate all occur¬ 
rences of serious function symbols. For example, 

F(x) <= if p(x) then a(x) 

else b(F(I(x)), Ffrfx))) 

produces the verification conditions 

Vx[p(x) =*• <Hx; o(x»], 

VxVz 1 Vz 2 [~p(x) & «K/(x); Zi) & » HrQc); z 2 ) & [/(x) = r(x) -ha - z 2 ] -* +(x; b{z u *))]. 

In the second condition the second and third conjuncts comprise formula B. The “func¬ 
tionality” condition C is not used in this paper but is useful for specifications which would 
otherwise be too weak to support the induction. Extensions to multiple equations are 
obvious, as are those to multiple-valued and nondeterministic functions. In our experience 
this is a powerful and natural method for explaining the correctness of recursive programs. 
Although subgoal induction is a partial correctness method, it can be extended to prove 
total correctness by including a performance measure in the specifications, just as the 
inductive assertion method can be so augmented [11]. 

3. Manipulating Continuations 

To illustrate the notion of a continuation, let us consider a function which reverses a list: 
Program 3.1 

REV(x) <= if x = [ ] then [ ] 

else append(REV(tl(x )), \hd(x)\) 

If REV is called with a nonnil list x, it proceeds to call REV on tl(x)\ given the value of 
REV(tl(x)), say w, the resulting answer is append{w, [Ad(x)]). Another way of expressing 
this idea is that the function \w.append(w, [hd{x)]) is applied to the argument REV{tl(x)). 
The function \w.append(w, [hd(x)]) is called the continuation [5, 6, 19, 20, 22-24, 26]. We 
can use this idea to rewrite RE V in the so-called continuation-passing style: 

Program 3 2 

REV2(x) e= REVC{x, \z z) 

REVC(x, y) «= ,= y(REV(x)) (see footnote 1) 

if x = 1 ] then v(l ]) 

else REVC(tl(x ), Atv y(append(w, [A<f(x)]))) 

Here the intended input-output specification is included as a comment. 

In order to fix our ideas about subgoal induction as a device for program explanation/ 
verification, let us prove: 

Proposition 3.1. REVCQc, y) = y(REV(x)). 

1 ,= may be read “is intended to equal.” 
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Proof. The specification \Prevc(x, y; z) is z = y(REV(xj). The verification conditions 
are 

(0 (* = □)=» ypREvc(x, Y, Y([ ])) and 

(ii) (x ^ [ ]) & \pREvc(tl(x), \w.y(append(w, [>W(x)])); z) => 4>revc(x, y, z). 

Substituting the definition of ^revc, we have to show 
(i) (* = [])=» (y([ ]) = y(REV(x))% 

( 11 ) (x * [ ]) & (z = (Xw.y(append(w, [hd(x)])))(REV(tl(x)))) => (z = y(REV(x))). 
Verification condition (i) follows immediately from the definition of REV. Condition (ii) 
is proved as follows: 

(x * [ ]) & (z = (\w.(append(w, [ hd(x)])))(REV(tl(x )))) 

=> (x ^ [ ]) & (z = y(append(RE V(tl(x)), [/id(x)]))) (8-reduction 2 ) 

=» z = y(REK(x)) (definition of using x^[]). □ 

The use of subgoal induction lets us prove the correctness of REVC essentially “line by 
line,” referring to the definition of REV and doing some simple manipulations. Henceforth, 
proofs of this sort will be left to the reader; the relevant input-output specification will be 
included as a comment. 3 Similarly, it is evident that if REV terminates (which it always 
does), then so does REVC. This may be proved by considering the performance specifi¬ 
cation 

' Prevc(x , y; z) ■ if y occurs as a first argument to REVC during the computation of 
REVC(x, y), then y occurs as a first argument to REV during the 
computation of REV{x). 

A brief consideration of the usual operational semantics of recursion equations (using, say, 
call-by-value) reveals that this specification is inconsistent with nontermination. Similar 
arguments throughout will be left to the diligent reader. 

Let us now make another observation about the operational semantics of REVC. 
In the computation of REV2(x), every value of y supplied to REVC is of the form 
Xv.append(v, a) for some a. To prove this, we observe that Xz.z is of this form (with 
a = [ ]), and if y = Xv.append(y, a), then 
Xw.y(append(w, f/irf(x)])) 

= Xw.((Xv.append(v, aj)(append(w, [Ad(x)]))) (definition of y) 

= Xw.append{append(w, [hd(xj\), a) (6-reduction) 

= Xw.append(w, append([hd(x)], a)) (associativity) 

= Xw.append(w, [hd{x) ! a]) (fact about append). 

Hence, instead of carrying around the function y, we can carry around the list a which 
represents it. Instead of writing y([ ]), we can write append ([ ], a) or just a. This gives us 

Program 3.3 

R£K3(x) <= REVC3(x , [ ]) 

RE VC3(x, a) <= ,= append(RE V{x), a) 

ifx = []thena 
else REVC3(tI(x), [ hd(x ) > a ]) 

which is just the usual “iterative reverse with accumulator.” This leads us to our key 
observation: An accumulator is often just a data structure representing a continuation 
function, 4 Data structures representing functions of some restricted type are widespread. A 
closure is of course a data structure; an association list is a representation of a function 

2 The operation of /{-reduction replaces an expression of the form (Ar t)a by t, with a substituted for all free 
occurrences of v> 

3 Just as one should include one’s invariants as comments. 

4 It would be nice to turn this observation into a theorem by replacing the word “often” by “always ” That, 
unfortunately, would require a formal definition of an “accumulator,” which is quite beyond the scope of this 
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if p(x) then a(x ) 
else b(F(c(x)), d(x)) 

where b is associative, with right identity 1 4 , is replaced by 
F'(x) <= FQx, L) 

FC{x, Y ) «= ,= b(F(x), Y ) 

ifp(x) then b(a(x), y) 
else FC(c(x), W y)) 

Fig 1 Replacement of associative continuation builder by accumulator 

from keys to values when the keys are atoms; 8 and the run-time stack is a machine-level 
representation of the top-level continuation [e.g., 19,26], Indeed, the identifier environment 
in which a program is run can be any data structure which can be used to map keys to 
values; even the form of the keys can be made arbitrary by preprocessing (see [22]). 

It is worthwhile to state Proposition 3.1 as a general transformation (Figure 1). 

Proposition 3.2. In Figure 1, F\x) - F(x). 

Proof. By subgoal induction on FC. The interesting case is ~p(x): 

FC(x, y) = FC(c(x), b{d(x), y)) 

= b(F(c(x)), b(d(x), y)) (induction hypothesis) 

= b(b(F(c(x)), d(x)), y) (associativity of b) 

= b(F(x), y). (definition of F). □ 

This transformation is well known; what is new in our discussion is the relationship 
between the accumulator and the continuation. 

Similar transformations for the nonassociative case have been considered by Strong 
[25], Let us take, for an example, McCarthy’s 91-function: 

Program 3 4 
F(x)<= 

if x > 100 then x - 10 else F(F(x +11)) 

In continuation form this becomes 

Program 3 5 

F2(x) <= F2-C(x, \z z) 

F2-C(x, y) *= . = y(F(x)) 

if x > 100 then y(x - 10) 
else F2-C(x + 11, \n> y(F(w))) 

Here again, we can obtain a closed form for the continuation: It is always of the form 
Xw.F(F(F- ■ ■ (w))) for some number of F’s. Hence we can represent the continuation by a 
counter. Unfortunately, it is more difficult to simulate y(x - 10) in this representation. To 
do this, we write a special function F3-SEND which simulates functional application for 
the given representation of the continuation: 

Program 3 6 
Fi(x) <= F3-C(x, 0) 

F3-C(x, i) <= = F u, (F(x)) 

if x > 100 then F3-SEND(x - 10, i) 
else F3-C(x+ 11, i+ 1) 

F3-SEND(v, i) <= ,= F“(v) 

if i = 0 then v ;the identity continuation 
else F3-C(v, i - 1) 

(Compare [12, Problem 3-5]). 

If more is known about the function, then a more finely optimized representation may be used, e g, a binary 
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When less is known about the continuation builders, then the representation of the 
continuation will perforce be less compact. In previous work we have considered the case 
where nothing whatsoever is known [27], Another case, also studied by Strong [25], is that 
of a single continuation builder with a parameter: 

Program 3 7 

if p(x) then a(x) 
else if q(x) then F(b(x)) 
else c(d(x), F(e(x))) 


Introducing continuations, we get 

Program 3 8 
F2(x) <= F2-C(x, Xz z) 

F2-C(x, y) <= ,= y(F(x)) 

if p(x) then y(a(x)) 

else if q(x) then F2-C(b(x), y) 
else F2-C(e(x), \w y(c(<i(jc), w))) 

Here again, we know a closed form for the continuation: 

\w.c(a u c(a 2 ,.... c(a n , w))). 

We can represent this continuation by [a„ a„-i • • • oi], giving 

Program 3 9 

Fl(x) «= F3-C(x, [ ]) 

F2-C(x, y) «= 

if p(x) then F3-SEN D(a(x), y) 
else if q{x) then F3-C{b(x), y) 
else F2-C(e(x), \d(x) ' y]) 

F3-SEND(v, y) <= 
if y = [ ] then r 

else F3-SEN D(c(hd(y), v), l/(y)) 

This is the well-known technique of replacing a single return address by a data stack [10, 
25]. 6 We chose to reverse the a,’s in the representation of the continuation so that the 
transformations of building and decomposing the continuations would be easily imple¬ 
mented in our list processing primitives. 

The correctness proof for (3.9) is not quite so straightforward as that for (3.8). In 
(3.8) we had the specification F2-C(x, y) = y(F(x)), In (3 9) y is no longer a function 
but is rather its representation. Hence the corresponding specification is F3-C(x, y) = 
F3-SEND(F(x), y). 

Proposition 3.3. For all x and y, F2-C(x, y) = F3-SEND(F(x), y). 

Proof. By subgoal induction on F. If p(x), then 

F3-C(x, y) = F3-SEND(a(x), y) (definition of F3-C) 

= F3-SEND(F(x), y) (definition of F). 


Otherwise, if q(x), then 

F3-C(x, y) = F3-C(b(x), y) (definition of F3-C) 

= F3-SEND(F(b(x)), y) (induction hypothesis) 

= F3-SEND(F(x), y) (definition of F). 

6 Note that in the original definition of F there were two recursive calls on F. The first of these, however, was tail- 
recursive, and so corresponds to the identity transformation on continuations Similarly, tail-recursive lines could 
be added to any of our examples without requiring global modifications 
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F3-C(x,y) = F3-C(*(x), [</(*) !y]) 

= F3-SEND(F(e(x)), [d(x)\y]) 
= F3-SEND(c(d(x), E(e(x))), y) 
= F3-SEND(F(x), y) 


(definition of F3-C) 
(induction hypothesis) 
(definition of F3-SEND) 
(definition of F). 


□ 


Proposition 3.4 F3(x) = F(x). 

Proof. F3(x) = F3-C(x, [ ]) = F3-SEND(F(x), [ ]) = F(x). □ 

By viewing these transformations as data-structure optimizations on continuations, we 
can consider other cases. We can use interactions between different continuation builders 
to find closed forms for continuations. The use of associativity was a primitive example of 
this, and another example appears in Section 5.2. Alternatively, we can use local contin¬ 
uations to represent parts of the global state, relying on the run-time stack to do the rest. 
Let us consider the following example: 


<**)«- 

if p(x ) then a(x) 
else if q(x) then b(G(c(x))) 
else d(G(l(x)), G(K*))) 


where b distributes through d, i.e., 

b(d(x,y)) = d(b{x), b(y)). 
We can then introduce a counter for the 6-builder: 


G2(x) «= G2-C(x, 0) 

G2-C(x, i ) <= ,= b u> (G(x)) 

ifp(x) then Gl-SEND(a(x ), i) 
else if q(x) then G2-C(c(x),, + 1) 
else 7 

The desired value in the place of the question mark is b il \d(G(l(x)), G(r(x)))). 
By the distributive law, this is equal to d(b M (G(l(x))), b u] (G(r(x)))) = d(G2-C(l(x), i), 
G2-C(r(x), /)). Thus we get 

G2-C(x, /) «= ,= b"'(G(x » 

if p(x) then G2-SEND(a(x), i ) 
else if q(x) then G2-C(c(x), i + 1) 
else d(G2-C(l(x), i), G2-C(r{x), /)) 

G2-SEND(v,,) <= ,= *'» 

if i = 0 then v 
else G2-S£ND(f>(v), i - 1) 

Although the conditions for this transformation look somewhat restrictive, they arise in 
both the large examples we will do later. The result of this transformation is not yet in 
iterative form [15], as the previous examples all were, but it has only a single line with a 
nontrivial continuation builder, and is therefore in a good form for further transformations. 
In Section 4 we consider some transformations applicable to binary recursion patterns such 
as this. 


4. Nonlinear Recursions 

The previous example showed how the user can retain control over the presentation of 
portions of the continuation while allowing the run-time stack to handle the “messier” 
portions, such as return addresses. In this section we will consider the case of nonlinear 
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Fig 2 Attribute-grammar patterns for recursion equations 
(a) nonlmear recursions, (b) linear recursion in continuation- 
passing style 



O accumulator - in 
• accumulator - out 


Fig 3 Attnbute-grammar pattern for nonlmear 


recursion patterns in more detail. In particular we will examine the following program: 
Program 4 1 

m<= 

If p(x) then a(x) 
else b(F(l(x)), F(r(x))) 

where b is an associative operation with an identity. We will see how one may use 
accumulators here without falling back on assignment, and how a nonpessimizing inter¬ 
preter will in fact mimic rather clever hand-compiled code. Last, we will see why in this 
situation one is led to consider the generalization “take a list of arguments,” or 

\l.MAPl(b, I 6 , MAP(F, 0) 

(a quite mysterious generalization!), and why this is usually wrong. 

We have written program 4.1 to suggest the traversal of some binary tree [10], where the 
trivial functions / and r select the left and right subtrees. In terms of attribute gram¬ 
mars [8] F computes a synthesized attribute, as do the original examples of Section 3. A 
continuation, however, is a summary of the tree above the current node, and is therefore 
an inherited attribute. (See Figure 2.) 

From our programming knowledge, we can observe that we would like to implement 
program 4.1 with an accumulator. The attribute-grammar pattern for this implementation 
is shown in Figure 3. 

How can we wnte this information flow pattern as a term in a recursion equation? If we 
set G{x, v) = b(y, F(x)), then 

G(x, v) = b(v, b(F(l(x)), F(rix)))) 

— b(b(v, F(l(x))), F(r(x))) (associativity of b) 

= b(G(l(x), v), F(r(x))) (definition of G) 

= G(r(x), G(l(x), v)) (definition of G). 

Thus we have 
Program 4 2 

F2(x) <= G2(x, h) ,= F(x) 

G2(x, v) «= ,= b(v, F\x)) 

if p(x) then b(v, a(x)) 
else G2(r(x), G2(/(x), v)) 
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where 1* is a left identity for b. The code generated for the last line of program 4.2 should 
go roughly as follows [22]: 

STACK r(x) ;the standard trick for inorder 

x <- l(x) traversals (See Ref. [10].) 

STACK [TAG1] ,the return address 
GOTO G2 

TAG1- v <- ANSWER ;retneve result of inner call 
x <— UNSTACK .thus retneving r(x) 

GOTO G2 .tail recurse 

Similar code may be generated for any term of the form F(t u u), where u is the first 

nontrivial subterm. 

Similar behavior may be obtained by interpreted code (in a static binding environment) 
if EVLIS is modified so that it does not store the calling environment across the evaluation 
of the last argument. Then all that is stacked across evaluation of u in F(t u ...,/„,«) is the 
list of values of h ,..., t n \ thus the behavior of the compiled code above is mimicked. We 
refer to this phenomenon as evlis tail recursion. 7 

We can still do better by hand, however, since we can take advantage (as an interpreter 
cannot) of the fact that there is only a single function symbol which is stacked, namely, 
G2. In other words, we have a single continuation builder with a parameter, and so we can 
apply the transformation of the preceding section to get our third version: 

Program 4 3 
F3(x)~G3(x,U,[]) 

G3(x,v )Y )<= 

if />(*) then SENDZ(b[v, a(x)\ y) 
else Gi(l(x), v. [r(*) ! 7 )) 

SENDZ{v, y) <s= 
if Y = [ 3 then v 
else G3(M( Y ), v, tl(y)) 

The transformation from program 4.2 to program 4.3 differs from the transformation 
from program 3.7 to program 3.9 only in regard to the else line (setting q(x) = false in 
program 3.7). Let us check this verification condition. 

Proposition 4.1. G3(x, v, y) * SEND3(G2(x, v), y). 

Proof. We proceed by subgoal induction on (72. The only verification condition which 
differs significantly from those in Proposition 3.3 is the last, the case where p(x) is false. 
The verification condition is 

~p(x) & \M/(x), v ‘. 2i) & <Po2(r(x), zi, Zi) =» x, v; z 2 ). 

(Here we have ignored the superfluous functionality condition.) Assuming the hypotheses, 
we calculate: 

G3(x, v, y) = G3(l(x), v, [r{x) ! y]) (definition of (73) 

= SEND3(G2{l(x ), v), [/■(*)! y]) (induction hypothesis) 

= G3(r(x), G2(l(x), v), y) (definition of SEND3) 

= SEND3(G2(r(x), G2(/(x), v)), y) (induction hypothesis) 

= SEND3(G2(x, v), y) (definition of G2). □ 

Proposition 4.2. F3(x) = F(x). 

Proof. F3(x) = G3(x, L, [ ]) = SEND3(G2(x, U), [ ]) = G2(x, l„) = F2(x) = 
F(x). □ 

7 The idea of evlis tail recursion was discovered jointly with D.P Fnedman and D S Wise Like tail recursion, 
evlis tail recursion can dramatically improve the space performance of many programs 
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Program 4.3 is in iterative form [15] and so does not require use of the run-time stack. 
Note that G3 and SEND3 are mutually tail recursive; this corresponds to the use of goto’s 
in the iterative code. Since we have derived this program from a more structured one by 
provably correct transformations, we conclude that here the use of the goto is permissible 
[10], While this code uses the goto, the correctness proof bears little, if any, resemblance to 
a correctness proof for program 4.3 using the inductive assertion method. The structure of 
the proof followed not the “object code” (program 4.3) but rather the “source code” 
(program 4.2), and is hence much easier. 

Some other observations about program 4.3 concern the sole appearance of b. Its second 
argument is a{x), where p(x) is true. If b is a user function which is complicated but known 
to be associative, it may be optimized to take advantage of this fact. (We use this later.) 
Furthermore, the values of v are all of the form b(b(b( 1 6 , a t ), a 2 ), .... a n ). Hence this 
version is most suitable for b’s which prefer to associate to the left. For b’s which are 
cheaper to associate to the right (like append ), one can get a similar program based on 
G(x, v) ;= b(F(x), v). Furthermore, we can take advantage of the way the values of v are 
built. If b is, say, conjunction, and some a(x) comes out false, then we can exit immediately, 
rather than calling SEND3 again. Note that this may cause F3 to converge when the 
original F diverged! 

We next consider some transformations which we might use to restore some “structure” 
to the “goto” program (program 4.3). We first observe that for any t and u, 

SEND3(v, [t «! y]) = G3(t, v, [u ! y]) 

by unwinding the definition of SEND3. We unwind the call to G3 in the definition of 
SEND3 to get 

SEND4(v, y) o ,« SEND3(v, y) 

if y = [ ] then v 

else if p(hd(y)) then SEND4(b(v, a(hd( y))), tl( y)) 
else G3(/(A4(y», v, [r(W(y)) ' t/(y)]) 

Using the previous identity we get our next version 
Program 4 4 

F4(x) «= SEND4(U, [*)) 

SEND4(v, y) <= ,= SENDMy, y) 

ify = [ ] then v 

else it p(hd( y)) then SEND4(b(v, a(hd(y))), I/(y)) 
else SEND4G, [/(«(?)> r(hd(y)) ' (7(y)]) 

Note that SEND4 is just a while-loop and may therefore be claimed to be “more 
structured” than program 4.3, which requires unrestricted gotos. 

Proposition 4.3. SEND4(v, y) = SEND3(v, y). 

Proof. By subgoal induction on SEND4. □ 

Proposition 4.4. F4(x) = F(x). 

Proof. F4(x) = SEND4(\ b , [jc]) = SEND3(\ b , [*]) = G3(x, h, [ ]) = F3(x) = 
F(x). □ 

We may further transform program 4.4 by observing that SEND4 treats its first argument 
as an accumulator and is therefore the target of a transformation like that of Figure 1. We 
invert the transformation to get 
Program 4 5 
F5(x) <= SEND5([x]) 

SEND5(y) ** 
if y = [ ] then t 6 

else if p(hd(y)) then b(a(hd( y)), SEN D5(t/(y))) 
else SENDS([I(hd(y)) r(hd( y)) ' t/(y)]) 
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Proposition 4.5. SEND4(v, y) = b(v, SEND5(y)). 

Proof. By induction on SEND5. □ 

Proposition 4.6. F5(x) = F(x). 

Proof. F5(x) = SEND5([x]) = 6(4, SENDS([x])) = SEND4(l b , [x]) = F4(x) = 
F(x). a 

SEND5 is the generalization of F to take a list of arguments instead of a single 
argument—a generalization which seems a priori nonobvious. If, however, one set about 
to optimize SENDS, one would first introduce an accumulator for the associative builder 
on the p(hd(y)) line. One might then observe that after the final call to SEND5, y is 
guaranteed to be unequal to [ ], and therefore introduce an inner loop to avoid the y = 
[ ] test. One might then spread hd( y) in a separate register. The result of these changes 
would be nothing other than program 4.3. 

One last note is in order. If one has an equivalence relation R on the data objects, and 
one is willing to weaken Proposition 4.6 to “F5(x) and F(x) are equivalent modulo R,” 
then b need not be associative: One need only that b(x, b(y, z)) and b(b(x, y), z) are 
equivalent modulo R. 

5 Examples 

In this section we shall do two fair-sized examples: a-/? tree searching and the conversion 
of formulas of propositional logic to conjunctive normal form. 

5.1 a-fi Tree Searching. We wish to do minimax searching of a game tree. We 
assume that every node is either a leaf node with a numeric value or else has associated 
with it a nonnull list of sons. We have two functions, F + and F~, which seek to maximize 
and minimize the values associated with a node: 

Program 5 1 1 
F(r)<= 

if leaf!(x) then value(x ) 
else max(MAPHD(F~, sons(x))) 

F-(x)«= 

if leaf>(x ) then vatue(x ) 
else mm(MA PHD(F*, sons(x))) 

Our first step is to eliminate the instances of MAPHD by standard transforma¬ 
tions [2]: 

Program 5 1 2 
F2 + (x)«= 

if leaf!(x) then value(x) 
else G2*(sons(x)) 

G2 + (i) «» 

if tl(l) = [ ] then F2-(hd(l)) 
else max(F~(hd(I)), G2*(tl(l))) 

KT(x)«= 

if leaf!(x) then value{x) 
else G2~(sons(x)) 

G2-(/)«= 

if»/(()“[ ] then F2*{hd(l)) 
else min(F2*(hd(l)), G2~(tl(l))) 

We notice that we have two associative continuation builders, max and min. Further¬ 
more, under reasonable conditions they commute with each other: 
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Proposition 5.1.1 

(i) If a < P, then max(ct, min(fi, v)) = min(fi, max(a, v)). 

(«) If a < P, then a < max( a, min(P, v)) < p. 

(Hi) max(v, min(x, y)) = min(max(v, x), max(v,y)). 

(i'v) min(v, max(x,y )) = max(min(v, x), min(v.y )). 

We therefore consider the conditional generalization 

FY(a, ft, x) <= ,= max(a, mm( p, F2\x))) if a £ P 

if leap(x) then max(a, mm( /?, value(x))) 
else G3 + (a, /?, sons(x)) 

G3*(a, £,/)<= ,= max(a, mm( p, G2*(/») ifa£/S 

if </(/)-[ ] then /-3-(a, P, hd(l)) 
else max(a, mm(/J, max(F2-(hd(l)), G2 + (t/(/))))) 

and the simultaneous symmetric generalization for the pair of minimizing functions. Using 
the associative and distributive laws (Proposition 5.1.1), we obtain 

max(a, min (P, ma x(F2~(hd(l)), G2*(tl(l))))) 

= max(max(a, min(y8, F2'(hd(l)))), max(«, mi^^, G2 + (f/(/))») 

= max(f 3'(«, P, hd(l)), max(«, min (P, G2*(tl(l))))). 

Introducing a help function for this continuation of FT, we obtain 

G4 + (a, P, l) <= ,= G3 + («, P, l) 

if //(/) = [ ] then FT (a, P, hd(I)) 
else H4*(a, p, tl(l), FY(a, p, hd(l))) 

HT(a, P, l, v) «= max(v, max(a , mm(J3, G2 + (/)))) 

But aSvSft so 

max(v, max(a, min( P, G2 + (i)))) 

= if v > P then v else max(v, min(/3, G2 + (/))). 

Substituting this for H4, we reach 

F5*(a, p, x) «= 

if teaP(x) then max(a, mm(P , value(x))) 
else G5 + (a, P, sons(x )) 

G5 + (a, p, l ) «= 

if tl(l) = [ ] then F5~(a, p , hd(l)) 
else H 5 + (a, p, tl(l), F5'(a, p, hd(l))) 

HY(a, P, I, v) <- 
if v > p then v else GY(v, p, I) 

and the simultaneous corresponding minimizing functions. Here H 5 performs cutoff. 

This example is interesting because a-P cutoff is usually justified by referring to a picture 
of the global tree, rather than by a program transformation argument [9]. Indeed, a possible 
criticism of recursive procedures is that they induce a premature contraction of the state 
space; in this example, the choice of state space inherent in the original version (program 
5.1.1) would seem to preclude the introduction of insights derived from the global state. 
Here, however, the continuation variable supplies precisely what is needed: a window 
allowing the global state to be included in the local state. (In retrospect this might have 
been expected, since the true state space of a set of recursive procedures includes the run¬ 
time stack as a ghost variable. It is surprising nonetheless that this state is accessible in 
comprehensible form at the source level [18].) 

5.2 Conjunctive Normal Form. Given a formula of the propositional calculus 
involving implication, negation, binary conjunction, and binary disjunction, we are asked 
to produce a formula logically equivalent to the original and which is in conjunctive 
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normal form (c.n.f.) [3], that is, of the form 

Cl & C 2 & • • ■ C n , 

where each C, (called a clause) is of the form 

h V • • • V lm., 

where each lj (called a literal) is a propositional variable or its negation. Traditionally, 
such a formula is produced by first removing implications and then driving negations 
inward, via the rales: 


A => B —* ~A V B, 

~(A & B) -» ~A V ~B, 

~(AV B)-*A& ~B, 

— A—A. 

Then the distributive law 

(A & B) V (A V C) & (B V C) 
and its variants are applied until the task is completed. 

Removing implications and driving negations inward are straightforward programming 
tasks; distribution seems somewhat harder, since it is not immediately clear how one can 
do better than say, “Search the entire formula for a possible rewrite.” Furthermore, one 
must switch at some point from binary operations to n-ary operations; this conversion is 
not discussed in the standard sketch of the algorithm. We will therefore concentrate on the 
distribution task. 

We will assume the input formulas are given in some abstract form, but we will use a 
concrete representation for the output formulas: A clause is a list of literals, and a formula 
is a list of clauses. 

We make the following try at a program: 8 
Program 5 2 1 
CNFl(x) «= 
if hteraP(x) then [[xj] 

else if conj^(x) then append(CNF\(op\ (x)), CNF\(op2{x))) 
else if dtr;?(x) then DISTR(CNFl(opl(x)), CNFl(op2(x))) 

where DISTR is a function (yet to be written) which performs approximately as follows: 
DlSTR{Ci & ■ • • & C n , Di & ■ • • & D m ) = (Ci V Di) & (Ci V D 2 ) & • • • & (C n V D m ), 
taking two formulas in c.n.f. and returning the n X m clauses in the c.n.f. of their 
disjunction. Such a function looks like it would take some care to Code correctly; 
furthermore, it would seem to involve considerable recopying of lists with the attendant 
inefficiency. We observe, however, that the specifications for DISTR require that it be 
associative (at least up to logical equivalence), with [[ ]], the false formula, as an identity, 
so we can use the transformation of the last section, getting 

Program 5 2 2 

CNF2(x) <= G2(x, [( ]], [ ]) 

G2(x, v, y) *- - S2(DISTR(v, CNF l(x)), y) 

if literaP{x) then S2(DlSTR(v, [[x]]), y) 
else if conji{x) then S2(DISTR(v, append(CNFl(opl(x)), CNF\(pp2(x)))), y) 
else if clisj ?(x) then G2(opl(x), v, [op2(x> ! y]) 

S2(v, y) *= 
if y = [ ] then v 
else G2(hd(y), v, tl( y)) 

8 Here we use “else if disjl(x) then ..” rather than “else..to remind the reader of the conditions under which 
the final clause is executed 
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ill 


Here we regard CNF l as a “trivial” function—though we must, of course, eliminate it 
before we are done! 

We now note that DISTR(X, append(Y, Z)) = cnf(* V (Y & Z» = cnf((Z V Y) & 
(.X V Z» = append(DISTR(X, Y), DISTR(X, Z», where = denotes logical equivalence 
among representations of c.n.f. formulas. 9 So the conjunction branch may be simplified to 

S2(append(DlSTR(y , CNF\(op\(x))), 

DlSTR(v, CNFl(op2(x)))), 

Y) 

We can achieve a fold if we can prove: 

Proposition 5.2.1. S2(append(x, y), y) = append(S2(x, y), S2(y, y)). 

Proof. We consider 

S2'(v,r)~ ,= S2(v, r ) 

if 7 — [ ] then v 

else S2'(DISTR(v, CNF\(hd(y))), illy)) 

S2'(v, y) = 52(v, y) follows by subgoal induction on 52' using the fact that G2(x, v, y) = 
S2(DISTR(v, CNF I(x)), y). We then prove the proposition (Vx, y)[S2'(append(x, y), y) 
= append(S2'(x, y), S2’(y, y»] by induction on y. If y = [ ], then both sides equal 
appendix, y). If y ¥= [ ], then 

S2\append{x, y), y) 

= S2\DISTR(append(x, y), CNF\(hd{y))), tl( y)) 

= S2'(append(DISTR(x, CNFl(hd(y))), DISTR(y, CNF\(hd(y)))), tl( y)) 

(by the argument above) 

= append(S2\DISTR(x, CNFl(hd(y))), tl( y)), 

S2\DISTR{y, CNF\{hd{y))), tl( y))) (induction hypothesis) 

= append(S2'(x, y), S2'(y, y)). □ 

By Proposition 5.2 1, we can simplify the conjunction branch to 

append(S2(DISTR(v, CNFl(opl(x))), y), 

S2(DISTR(v, CNFl{op2(x))), y)) 
which we fold with G2 to obtain 

Program 5 2 3 

CNF3(x) ^ G3(x, [[ ]],[ ]) 

G3(x, v, 7) <= ,= S3(DlSTR(v, CNF 1(jc)), y) 

if lneraP(x) then S3(DISTR(v, [[x]]), 7) 
else if conji(x) then append(G3(opl(x), v, 7), G3(op2(x), v, 7)) 
else if disfix) then G3(opl(x), v, [op2(x) • 7]) 

«(v,7)^ 
if 7 = [ ] then v 
else G3(hd(y), v, tl( 7)) 

Before proceeding further it is worth examining program 5.2.3 to see if we can make some 
intuitive sense out of its components. We first notice that in the only call to D1STR, the 
second argument is a formula consisting of a single literal: 

DISTR(C\ & • • • & C n , [[*]]) = (CiV x) & ■ ■ ■ & (CnV x). 

This simplification would surely make DISTR much easier to write, but we can observe 
something stronger. Every value of v is a formula consisting of a single clause. This is true 
because v starts out as a formula of one clause ([[ ]]), and the only operation which 

9 Here cnf(X) means “some c n f of X" rather than the c n f produced by some particular program 
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changes v is DISTR(v, [[*]]), which preserves this property. Therefore we can represent v 
as a clause instead of a formula; then DISTR(Ci, [[*]]) is logically equivalent to [x ! CJ. 
We therefore rename v to lits, since it accumulates literals into a clause. We also rename 
y to rest, since it stores the rest of x which will be processed later. These changes yield 

Program 5.2 4 
CNF4(x) <m GMx, [],[]) 

G4(x, lits, rest) <= ,= S4{DISTR([hts], CNFl(x)), rest) 

if literal^x) then 54([jc ' /its], rest) 

else if conp(x) then append(G4(op\(x), hts, rest), 

G4(op2(x), hts, rest)) 

else if dtsj r> (x) then G4(op\(x), hts, [op2(x )' rest]) 

S4(hts, rest) <= 
if rest = [ ] then [/its] 
else G4(hd(rest), hts, tl(rest)) 

With program 5.2.4 we once again have a single associative continuation builder, append, 
so we can eliminate the recursion entirely by applying the transformation of Section 4 
once again. Here we must be a little careful, since we have two mutually recursive functions 
instead of one. We name the accumulator clauses. The result is 

Program 5 2 5 

CNFS(x) = GS(x, [],[],[],[]) 

G5(x, hts, rest, clauses, y) «= 

,= SEND5(append(clauses, G4{x, hts, rest)), y) 
if literaVKx) then S5([x ! hts], rest, clauses, y) 
else if conjt(x) then G5(opl(x), hts, rest, clauses, [op2(x), hts, rest ' y]) 
else if dtsjt(x) then G5(op\{x), hts, \pp2(x )' rest], clauses, y) 

S5(hts, rest, clauses, y) «= 
if rest = [ ] then SEND5([hts ' clauses], y) 
else G5(hd(rest). hts, tl(rest), clauses, y) 

SEND5(clauses, y) <= 
if y = [ ] then clauses 

else G5(hd(y), hd(tl(y)), hd{tl(tl{ y))), clauses, tl(tl(ll(y)))) 

This is not quite the last word, however. We can prevent the inclusion of tautologous 
clauses by replacing the literal branch of G5 in program 5.2.5 by 

if literal tlx) then 

if tautology''(x, hts) then SEND5(clauses, y) 
else S5([* 1 hts], rest, clauses, y) 

and we can similarly eliminate subsumed clauses [3] by changing the first branch of S 5 to 
be 


if rest = [ ] then 

if subsumed \ltts, clauses ) then SEND5(clauses, y) 

else SENDSIJJits ' clauses], y) 

Either of these changes would have required an escape or similar major surgery on any of 
the previous versions, since the necessary variables were hidden from the local state space. 

6. Conclusions 

We have presented a technique for producing generalizations of functions as a step in the 
program transformation process. In this technique one generalizes by adding a variable 
corresponding to the continuation or global context m which the local computation takes 
place. One can often express the continuation or portions of it in closed form; one can then 
use standard local simplification techniques. This allows recovery from the premature 
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contraction of the state space that sometimes accompanies recursive programming styles. 
If a closed form is known, then data structure optimizations may be used to obtain an 
efficient representation of the continuation. 

This generalization technique is complementary to the ones suggested in [2], which seem 
to be aimed toward finding uses for their abstraction rule to eliminate redundant function 
calls. Our local manipulations are, of course, similar to theirs; our contribution is an 
account of the origin of the additional variables in the generalization. 

We have given two moderate-sized examples of the technique, involving repeated 
applications of these transformations. Other examples where these ideas have been applied 
include: the equal-tips problem, backtrack programs (e.g., [4, pp. 63-66]), finding all 
factors of a clause [3, p. 80], and implementing semantic resolution [3, Ch. 6], 
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